Forms are well known to most people, and area a part of everyday life. Most people are consumers of forms, rather than producers or designers of forms. In order for a software product to utilize forms, someone first had to work towards the act of developing the form. It is important to distinguish between the ‘form’ that the creator designs, and the ‘form’ that a consumer handles—they both represent the same form, but at two very different stages in the form's life cycle.
To an end user (form consumer), a form represents something to be filled out, by entering data into the white spaces. There is little or no distinction between a blank form and a filled form, other than the presence of data. In fact, the absence of data in a particular data entry element can be as meaningful as the presence of data.
In contrast, a form designer views a form as a vehicle for capturing, rendering and manipulating data. As such, the designer is concerned with issues of layout, interaction and processing. A template is a specification of capture, rendering and manipulation rules that apply to form instances created from that template.
A form is the result of combining a form template with data. This includes the initial case of a blank form, which is a form template with an empty data set. An end-user (form consumer) interacts with a form for several reasons. Among these reasons are to fill the form interactively, to view a form which was filled by another user, to print the form or to submit the form to another process, such as a workflow process.
When selecting a form to be filled interactively, the user perceives that they are selecting a blank form. The user is performing an operation similar to starting a new document in a word processor, by first selecting a template. The user selects this template that the form-filling application uses to construct a form, which at first appears blank.
The user may fill out the form, and save the data content to a file or a database. It is important to note that the data was saved, not the form (and not the form template). Some time later, the user may select the same template, a form is displayed, then proceeds to reload the previously produced data into the form. Alternately, the user may select the previously saved data, and the template is automatically retrieved by some association stored between the form and data. There are also cases where the entire state of the form (data and template) need to be saved together
A form is composed of objects that the user perceives as the form content, such as the graphical and textual content that is part of the static form design, and the content present in the fields typically provided by a user. These content objects are arranged within the template coordinate space and presented to the user by enclosing the content within container objects such as draw, field, area, or subform container objects.
As mentioned above, a template represents the potential for a form. A template is a non-geographical grouping of objects. The template represents the form design as a whole, enclosing all of the objects and intelligence of the form. A template is a collection of related subforms and processing rules. A form designer interacts with the form template for several reasons. These reasons include designing a new template from scratch, designing a new template based upon one or more existing templates or modifying an existing template.
Form content refers to any piece of data that may appear on a form. Content includes, but is not necessarily limited to, interactive data (enclosed in field elements), static data (enclosed in draw elements), textual data (both plain and rich), and graphical data (e.g., lines, boxes, images and the like).
The end user, while aware of a form's interactive content, generally doesn't make a distinction between that content and the field that houses it. However, the distinction is important to the form designer. Content elements tend to be concerned with data related issues (e.g., data type and limitations), while field elements are concerned with presentation and interaction.
A container or container object refers to an element that houses a piece of content. The container is concerned with all form-related aspects of dealing with its content. These include rendering, interactions with the user interface, data entry sequencing, calculations and other interactions with other containers/content.
A field is a container element that houses one piece of dynamic content of a form. As instances of forms are created from a common template, the static content is generally the same across those instances. However, the dynamic content is very likely to change from instance to instance.
The end user filling out a form effects change to dynamic content. Often, the user interacts with a field via data entry (typing). However, every interactive element on a form is a field. Accordingly, pushbuttons, check-boxes, and even some images are also fields. The end user is not the only source of change to dynamic content. Applications, database input, dynamic calculations and many other sources can also change this content.
The content within a form template is presented to the user by enclosing the content within container objects. Containers determine the layout and formatting of the form content and include the field element described above, as well as the draw, area, subform and exclusion group elements.
Forms invariably contain static content. This content, often referred to as boilerplate, typically provides context and assistance for consumers of the form. A draw element encloses each piece of static content. A user cannot directly interact with a draw object. The draw element content is not limited to text. For example, a line element is legitimate content for a draw element.
A field object is the workhorse of a template, and represents a data-entry region. A user is typically expected to interact with the fields by providing data input. Fields provide a pluggable user interface and support for a broad variety of content data-typing.
Every container has the notion of a value. This container value can be used in calculations and may be persisted when the form's data is saved. For draw and field containers, the value is the container's content. For containers of containers (area, exclusion group and subform), the value of the container is the value of one of the child containers. The rules for determining which child container's value to use are described with each container element. It should be noted that the container value is more than a read-only property. There are operations that can set a container's value, even if the container is a container of other containers.
Content is available in a variety of types. These types include arc, boolean, date, datetime, decimal, exdata, float, image, integer, line, rectangle, text, and time. Other content types may also be used.
It should be recognized that not all types of content are appropriate everywhere on a form. Specifically, while it may be possible for all of the content types to be rendered on the form, it is likely that user will have a restricted set of content types that may be used for data input into the form.
Draw content refers to the set of possible content elements that can be enclosed inside a draw object, and this corresponds to the entire set of content types. Thus, while practically all content objects can be presented or ‘drawn’, a form filling application may not be capable of providing a method for the user to input all types of content objects.
For example, a typical form will have textual content presented on the form itself (providing field labels and instructional text to the user) and permit the user to input textual content into the fields of the form. Another draw content type presented on forms includes rectangles and lines that provide the graphical composition, but the user would not typically have the ability to input a line or a rectangle into a field on the form.
Field content is the subset of the available content types that a user can input with a form filling application and may be enclosed inside a field object. The majority of form field content is textual or numeric data.
A subset of content objects may be specified as the minimum that a form filling application should permit within a field container. This subset may include boolean, date, datetime, decimal, exdata, float, image, integer, text, and time.
Null values have a traditional significance with databases, where it is important to have a means to explicitly signify the lack of a value. A database table column may be permitted to hold null values, and this is used in the screen-based data entry forms and subsequent queries as a means of identifying or excluding the table columns that have no value. It is common to construct a query that selects database table rows where one or more criteria are not null.
This requirement and subsequent usage of null values also applies to electronic forms, where it is often important to distinguish fields that have no value, and exclude these same fields from calculations. For instance, given a form that accepts up to ten numbers and calculates the average, the form has ten entry fields and one calculated displayed average field. The user is not required to provide ten numbers; the user can provide as few or many numbers up to a maximum of ten. The correct calculation of the average is dependent upon excluding the empty fields from the average. Were all ten fields included in the average calculation, including the empty fields, the average could be skewed by accidentally considering empty fields to have a value of zero. In this example it is important that there be a straightforward way for distinguishing between null (empty) fields, and fields where the user has explicitly typed a value including a possible zero value.
Content elements are capable of holding a value of null. This is, by default, the value of an empty content element. Content elements also have an attribute that permits this behavior to be changed. As previously described, empty content elements are null by default—adjusting this attribute will require that null values be explicitly specified with a <Null/> element.
Note that with text content, there is a distinction between null content and empty content. In general, processing applications deal with null content in ways that are intuitive to the end user. For example, a text field that contains null content and a text field that contains an empty string will often be treated as being identical, unless the form designer explicitly wants to take advantage of null content.
When developing internationalized applications, a locale is the standard term used to identify a particular geopolitical region. A locale defines (but is not limited to) the format of dates, times, numeric and currency punctuation that are culturally relevant to a specific nation. A properly internationalized application will always rely on the locale to supply it with the format of dates, and times. This way, users operating in their locale will be presented with the date and time formats they are accustomed to.
A locale is identified by a language code and/or a country code. Usually, both elements of a locale are important. For example, the names of weekdays and months in English, in Canada and in the UK are formatted identically, but dates are formatted differently. So, specifying an English language locale would not suffice. Conversely, specifying only a country as the locale may not suffice either—for example, Canada, has different date formats for English and French.